In che modo Atlassian garantisce la prontezza operativa

Anche con strutture di progetto moderne come DevOps, molti progetti non dispongono di una procedura di pianificazione essenziale: un processo automatizzato di valutazione della prontezza. Senza la prontezza operativa, i team di sviluppo software non sanno se l'ambiente è in grado di supportare un nuovo sistema o prodotto. Tuttavia, la prontezza operativa non è un aspetto a cui pensare poco prima della distribuzione. È importante integrarla tempestivamente al momento della creazione dei requisiti e delle specifiche del progetto. 

Cos'è la prontezza operativa?

La prontezza operativa è un insieme di requisiti che i team di sviluppo devono soddisfare prima che il servizio sia pronto per la distribuzione in produzione. Questi requisiti vengono stabiliti da un team prima dell'inizio dell'attività di sviluppo. I requisiti di prontezza operativa obbligano i team a tenere conto dell'affidabilità, della sicurezza e della conformità sin dal primo giorno. Concentrandosi su questi requisiti sin dall'inizio, i team evitano che si verifichino problemi con i clienti dopo la distribuzione del servizio.

I componenti della prontezza operativa che i team devono definire sono tre. Innanzitutto, una serie di livelli di servizio; in secondo luogo, una serie di accordi sui livelli di servizio e infine una serie di requisiti. Ogni livello di servizio prevede un accordo sul livello di servizio e uno o più requisiti di prontezza operativa. Quando viene creato un nuovo servizio, gli viene assegnato un livello di servizio. L'accordo sui livelli di servizio stabilisce i requisiti di disponibilità, affidabilità, perdita di dati e ripristino del servizio. Un servizio deve soddisfare tutti i requisiti di prontezza operativa prima di poter essere distribuito in produzione. 

I contenuti riportati di seguito descrivono in dettaglio il processo di prontezza operativa di Atlassian e può aiutare i team ad avviare il proprio processo. Tuttavia, ogni organizzazione dovrà personalizzare le proprie procedure di prontezza operativa in base al lavoro e dell'ambiente.

Definizione dei livelli di servizio

I livelli di servizio consentono di raggruppare i servizi in bucket di facile comprensione. Ogni livello di servizio determina uno SLA e una serie di requisiti di prontezza operativa. Lo SLA e i requisiti di prontezza operativa si basano sui tipi di scenari di utilizzo riscontrati dai servizi all'interno del livello. I livelli di servizio possono essere considerati come "contenitori" (bucket) organizzati per importanza. Tutti i servizi presenti in un determinato bucket sono ugualmente importanti e devono essere gestiti nello stesso modo. Per un bucket di servizi critici rivolti ai clienti i requisiti saranno probabilmente più rigorosi rispetto a un bucket di servizi terziari che hanno un impatto solo sui dipendenti. 

I seguenti esempi di livelli di servizio si basano sui livelli di servizio di Atlassian:

• Livello 0: componenti critici che sono alla base di tutto.

• Livello 1: prodotti e servizi rivolti ai clienti.

• Livello 2: sistemi aziendali.

• Livello 3: strumenti interni.

Livello 0: infrastruttura di backbone critica

Un servizio di livello 0 fornisce l'infrastruttura di assistenza e i componenti di servizio condivisi necessari per il funzionamento dei servizi di livello 1. I componenti sono considerati fondamentali se si verifica una delle seguenti condizioni:

• Sono necessari per l'esecuzione di un servizio di livello 1 o per l'accesso dei suoi utenti.

• Sono necessari affinché un cliente possa effettuare la registrazione a un servizio di livello 1.

• Sono necessari affinché il personale possa supportare o svolgere funzioni operative chiave su un servizio di livello 1, come:

      - Avviare/Arrestare/Riavviare il servizio 

     - Eseguire una distribuzione, effettuare l'upgrade, il rollback o una correzione rapida     

     - Determinare lo stato corrente (attivo/non attivo/ridotto)

Livello 1: servizi essenziali

Un servizio di livello 1 fornisce una funzione fondamentale per l'azienda, il cliente o il prodotto. Si tratta di servizi rivolti ai clienti o di servizi interni business-critical. Quando si verifica un peggioramento delle prestazioni del servizio, l'azienda perde denaro o non è in grado di svolgere funzioni business-critical e/o per il cliente si verifica una perdita delle funzionalità essenziali. I servizi di livello 1 richiedono un'assistenza con reperibilità 24 ore su 24, 7 giorni su 7, hanno SLA elevati per le metriche chiave e una serie rigorosa di requisiti di distribuzione.

Livello 2: servizi non essenziali

Un servizio di livello 2 fornisce un servizio rivolto al cliente che non fa parte delle funzionalità principali. I servizi di livello 2 forniscono un valore aggiunto o un'esperienza utente aggiuntiva che potrebbe essere considerata opzionale o comunque preferenziale.

Un servizio di livello 2 include servizi pubblici che funzionano principalmente per finalità di marketing, ad esempio i siti Web di aziende quotate in borsa. Questi servizi non includono servizi diretti di livello aziendale ai clienti e servizi interni utilizzati dai team per svolgere le attività previste dai loro ruoli, come strumenti di collaborazione, monitoraggio dei ticket e altro ancora.

I servizi di livello 2 possono richiedere o meno l'assistenza con reperibilità 24 ore su 24, 7 giorni su 7, avere SLA meno rigorosi e un minor numero di requisiti di distribuzione.

Livello 3: funzionalità solo interne o non critiche

Un servizio di livello 3 fornisce funzionalità interne all'azienda o servizi beta. Questa classe può includere anche servizi che sono attualmente in fase sperimentale per i primi utenti e dove è prevista l'eventualità di un peggioramento delle prestazioni. Questo livello fornisce un bucket di SLA bassi per i servizi per i quali è prevista unicamente un'assistenza "al meglio".

Definizione degli SLA per i livelli di servizio

Gli accordi sul livello di servizio (SLA) definiscono gli obiettivi di disponibilità e affidabilità, e i tempi di risposta per gli eventi di interruzione del servizio. Per ogni livello di servizio è presente un accordo sui livelli di servizio. La tabella seguente fornisce un esempio di accordi sui livelli di servizio per ciascuno dei quattro livelli di servizio definiti in questo articolo.

SLA per livello di servizio

Disponibilità

Affidabilità

Perdita di dati (RPO)

Questo numero rappresenta la quantità massima di dati che verranno persi dal servizio in caso di guasto del servizio. Per un servizio di livello 0 si verificherà una perdita di dati inferiore a un'ora in caso di guasto del servizio.

Ripristino del servizio (RTO)

Questo numero rappresenta la quantità di tempo massima prima che il servizio sia di nuovo attivo e funzionante. Un servizio di livello 0 verrà ripristinato completamente in meno di quattro ore.

Definizione dei controlli di prontezza operativa

Un controllo di prontezza operativa rappresenta un test con risultato positivo o negativo per una specifica qualità di un servizio. È correlato alla disponibilità, all'affidabilità e alla resilienza del servizio piuttosto che alla funzionalità del servizio. I team devono definire la serie di controlli di prontezza operativa che utilizzeranno per determinare l'idoneità alla produzione. Questi controlli non sono universali. Alcuni saranno pertinenti solo per livelli di servizio specifici. Un servizio di livello 0, ad esempio, avrà requisiti più rigorosi di un servizio di livello 3. La sezione seguente fornisce esempi di controlli di prontezza operativa che possono essere utilizzati come punto di partenza. 

Backup

Quando si verifica un'interruzione di un servizio, i team potrebbero dover utilizzare i backup per ripristinare i dati a un determinato momento. È importante eseguire backup regolari dei dati, implementare un processo di ripristino e testare regolarmente il processo di backup e ripristino. Il processo di backup e ripristino dovrebbe essere affidabile ed efficace. In questo ambito la documentazione e i test sono fondamentali.

Definizione di "completato"

• Implementazione di un processo di backup e ripristino

• Documentazione e test del processo di backup e ripristino

• Test condotti regolarmente sul processo di backup e ripristino

   

Gestione della capacità

Descrivi chiaramente le capacità che il servizio offre ai consumatori. In particolare, identifica gli eventuali limiti che il servizio impone loro. Implementa test delle prestazioni per garantire che il servizio funzioni nell'ambito dei limiti previsti.

Ecco alcuni esempi di informazioni da testare e mettere a disposizione dei consumatori.

• Il servizio è limitato a X requisiti al secondo.

• Il servizio garantisce un tempo di risposta pari a X.

• La funzione X del servizio è o non è replicata in tutte le regioni.

• Il consumatore non dovrebbe fare X

  - sovraccaricare il servizio

  - caricare file più grandi di X

Definizione di "completato"

•  I limiti di servizio sono identificati e documentati.

•  Vengono condotti test delle prestazioni per verificare l'applicazione dei limiti

   

Consapevolezza dei clienti

La supportabilità è un aspetto importante della qualità del servizio che va di pari passo con l'affidabilità e l'usabilità. I team devono creare processi di assistenza per un servizio o una nuova funzionalità di un servizio prima che venga implementata. La supportabilità può includere un processo di assistenza clienti, un processo di controllo delle modifiche, runbook di assistenza e altri aspetti incentrati sull'assistenza.

Processo di assistenza clienti

Gli sviluppatori devono capire cosa succede quando i clienti contattano il team di assistenza e devono comprendere le proprie responsabilità con riferimento al processo di assistenza. Ciò può includere la partecipazione a una rotazione su chiamata o la richiesta di risolvere i problemi di produzione man mano che si verificano.

Processo di controllo delle modifiche

Non tutte le modifiche hanno lo stesso impatto sui clienti. Alcune sono impercettibili per i clienti, ad esempio, una piccola correzione di bug; altre comportano un impegno elevato da parte dei clienti, come una riscrittura completa di un'API. Il controllo delle modifiche aiuta a valutare l'entità dell'impatto che le modifiche potrebbero avere sul cliente.

Runbook di assistenza

I runbook forniscono una panoramica generale del funzionamento di un servizio, oltre a spiegazioni dettagliate dei problemi che possono verificarsi e su come risolverli. È importante aggiornare regolarmente i runbook e verificare che le procedure di assistenza documentate vengano aggiornate man mano che il servizio cambia nel tempo.

Definizione di "completato"

• Documentazione che risponde alla maggior parte delle domande che il team di assistenza potrebbe avere per condurre le dovute indagini su un problema.

• Un processo funzionante per il controllo delle modifiche

   

Disaster Recovery

Un evento disastroso comporta varie conseguenze, tra cui la perdita di una zona di disponibilità. I servizi devono disporre di una resilienza sufficiente per funzionare normalmente in caso di guasto di una zona di disponibilità. Il ripristino di emergenza ha due componenti: il primo serve per sviluppare e documentare un processo di ripristino di emergenza e il secondo per eseguire test continui del processo documentato. Il ripristino di emergenza deve essere testato regolarmente. Verifica la capacità di gestire un errore nella zona di disponibilità utilizzando il piano documentato di ripristino di emergenza.

Definizione di "completato"

• Il piano di ripristino di emergenza è documentato.

• Il piano di ripristino di emergenza è testato.

• Sono previsti test ricorrenti del piano di ripristino di emergenza

   

Registrazione

I log sono utili per innumerevoli motivi, ad esempio il rilevamento di anomalie, le indagini durante o dopo un'interruzione del servizio e il monitoraggio di attività dannose effettuato utilizzando identificatori univoci per connettere eventi correlati tra i servizi. Esistono molti tipi di log. Alcuni sono molto utili e dovrebbero essere inclusi nella maggior parte dei servizi. Tra questi:

• Log di accesso

• LOG DEGLI ERRORI

Definizione di "completato"

• Vengono generati i log appropriati

• I log sono archiviati in una certa posizione e sono facilmente reperibili e ricercabili

   

Controlli logici degli accessi

Lo scopo principale dei controlli logici degli accessi è quello di gestire l'accesso degli utenti interni, l'accesso degli utenti esterni, l'accesso da servizio a servizio e la crittografia dei dati. In che modo il servizio impedisce l'accesso non autorizzato a funzionalità e dati? Come vengono definite, verificate, aggiornate e deprecate le autorizzazioni utente? Questi controlli forniscono una protezione sufficiente per i dati sensibili?

Utenti interni

Ecco alcune domande importanti a cui rispondere: come vengono autenticati gli utenti interni? Come viene concesso/fornito l'accesso? Come viene revocato? In che modo funziona un'escalation di privilegi? Qual è la procedura per le revisioni e gli audit regolari degli accessi?

Utenti esterni

Come viene gestita l'autenticazione per i clienti? Come viene concesso/fornito l'accesso? Come viene revocato? In che modo funziona un'escalation di privilegi? Qual è la procedura per le revisioni e gli audit regolari degli accessi?

Da servizio a servizio

La procedura è simile a quella per gli utenti interni ed esterni. I team devono stabilire la modalità reciproca di autenticazione dei servizi, ad esempio configurando OAuth 2.0.

Crittografia

I team probabilmente vogliono crittografare i propri dati inattivi e in transito. In che modo il servizio gestisce la crittografia dei dati? In che modo il team gestisce le chiavi? Qual è la policy di rotazione delle chiavi?

Definizione di "completato"

• I controlli logici di accesso sono documentati, implementati e testati per gli utenti interni, gli utenti esterni e da servizio a servizio.

• I dati vengono crittografati quando sono inattivi.

• I dati vengono crittografati in transito.

• La crittografia è implementata e testata

   

Release

La distribuzione di una nuova versione del servizio non deve causare interruzioni nel traffico dei clienti in misura maggiore di quanto definito nello SLA dei servizi. Tutte le modifiche devono essere sottoposte a peer review, testate e distribuite tramite pipeline CI/CD. Verifica che ogni distribuzione effettuata sia andata a buon fine e non abbia causato alcuna interruzione nelle funzionalità. È preferibile la verifica automatizzata post-distribuzione. La disponibilità di più ambienti come test, staging, pre-produzione e produzione permette di testare le distribuzioni.

Definizione di "completato"

• Il servizio prevede una distribuzione senza tempo di inattività.

• In alcuni ambienti il servizio deve essere distribuito e testato prima di essere inviato in produzione

   

Checklist di sicurezza

La checklist di sicurezza è un insieme di pratiche e standard per lo sviluppo e la manutenzione di infrastrutture e software sicuri. Questi standard riducono la probabilità che si verifichino violazioni della privacy e dei dati e, di conseguenza, determinano una maggiore fiducia da parte dei clienti. I team devono sviluppare una checklist di sicurezza che tenga conto della natura del servizio che stanno creando. Ecco alcuni esempi di requisiti:

Definizione di "completato"

• Prova che non esistono vulnerabilità aperte, critiche o elevate per il servizio.

• Utilizzo della crittografia dei dati a riposo per tutti gli archivi dati.

• Prova che il servizio non consente connessioni HTTP non sicure

   

Metriche del servizio

Le metriche del servizio forniscono informazioni diagnostiche e di stato essenziali in relazione a un servizio e consentono ai team di monitorare e rispondere agli imprevisti. Inizia definendo una serie di metriche monitorate per ogni servizio. Quindi, crea una dashboard con queste metriche in uno strumento come Datadog o New Relic. Attiva allarmi quando una metrica supera i limiti e genera ticket di problemi in caso di allarme.

Definizione di "completato"

Ecco alcuni esempi di aspetti da misurare:

• Latenza: il tempo impiegato per gestire una richiesta.

• Traffico: carico sul servizio da parte di utenti esterni.

• Errori: numero di utenti che influiscono su errori o guasti.

• Saturazione: livello di occupazione del servizio e disponibilità residua.

• Utilizzo delle risorse sottostanti: CPU, memoria, disco.

• Elenchi interni dell'applicazione come code, tempistiche e flusso.

• Utilizzo e funzionalità principali del servizio: utenti attivi, azioni al minuto

   

Resilienza del servizio

I requisiti di resilienza del servizio determinano se un servizio è in grado o meno di gestire le modifiche di carico e/o i guasti di vari componenti. Un servizio resiliente è probabilmente scalabile in modo automatico e in grado di resistere ai guasti di un singolo nodo.

Scalabilità automatica

Se il servizio è scalabile automaticamente, assicurati che la scalabilità automatica sia testata e configurata in modo appropriato. Determina la metrica che attiverà la scalabilità automatica e testala per verificarne il funzionamento. Ad esempio, se il servizio richiede l'archiviazione di dati su disco, può monitorare la percentuale dello spazio libero sui dischi ed è scalabile automaticamente aggiungendo spazio di archiviazione quando la percentuale di spazio libero scende al di sotto di una determinata soglia.

Test dei guasti di un singolo nodo

È auspicabile disporre di servizi in grado di continuare a funzionare qualora si verifichi un guasto di un singolo nodo. Se un singolo nodo di servizio non funziona, il servizio dovrebbe continuare a funzionare, anche con una capacità ridotta. Prova a effettuare questa verifica terminando almeno un nodo del servizio e osserva il comportamento del sistema. Il servizio dovrebbe essere in grado di gestire il guasto di un singolo nodo. L'ambiente in cui simulerai un guasto di un singolo nodo deve essere monitorato.

Definizione di "completato"

• Prova che la scalabilità automatica è implementata e testata.

• Prova che gli ambienti di produzione e/o di staging eseguono più nodi.

• Prova che il servizio è resiliente a un guasto di un singolo nodo

   

Supporto

L'assistenza è il processo di assistenza per un servizio fornito dopo il rilascio. I team devono disporre di runbook, strumenti operativi e rotazioni su chiamata prima di effettuare la distribuzione dei servizi, in modo che sia presente un processo per correggere i servizi con problemi.

Runbook

I runbook forniscono agli addetti alla risposta su chiamata il contesto e le istruzioni di cui hanno bisogno per gestire la riposta rapida agli imprevisti e le attività di correzione.

Strumenti operativi

Eseguire un servizio in conformità a uno standard sufficiente significa che è disponibile la reperibilità su chiamata e che è configurato uno strumento operativo come Opsgenie per inviare avvisi su chiamata in caso di problemi del servizio.

Reperibilità

Per un servizio di livello 2 e 3 è richiesta la reperibilità su chiamata.

Per un servizio di livello 1 è richiesta la reperibilità su chiamata 24 ore su 24, 7 giorni su 7.

Definizione di "completato"

• I runbook sono scritti e reperibili dall'assistenza.

• Lo strumento operativo è configurato e testato.

• Sono implementate rotazioni in base alla reperibilità e il personale viene contattato in caso di problemi

   

Definizione dei controlli di prontezza operativa per i livelli di servizio

Dopo aver definito una serie di requisiti di prontezza operativa, il team deve stabilire quali sono i relativi requisiti appropriati per ogni livello di servizio. Alcuni requisiti di prontezza operativa sono appropriati per tutti i livelli di servizio, mentre altri possono essere indicati solo per i servizi di livello 0. Inizia con il livello di servizio più basso e aggiungi progressivamente i requisiti ai livelli superiori. I servizi di livello 3 potrebbero avere alcuni requisiti di prontezza operativa di base, mentre i servizi di livello 0 richiederanno tutti i requisiti di prontezza operativa.

Controlli di prontezza operativa suggeriti di livello 3

• Backup

• Registrazione

• Release

• Checklist di sicurezza

• Metriche del servizio

• Supporto

   

I servizi di livello 3 iniziano con i requisiti di prontezza operativa di base.

Controlli di prontezza operativa suggeriti di livello 2 e 1

• Backup

• Disaster Recovery

• Registrazione

• Release

• Checklist di sicurezza

• Metriche del servizio

• Resilienza del servizio

• Supporto

I servizi di livello 2 e 1 aggiungono requisiti di prontezza operativa per il ripristino di emergenza e la resilienza del servizio. È importante notare che i servizi di livello 2 e 1 potrebbero avere requisiti di prontezza operativa diversi. Non è necessario che i livelli abbiano requisiti diversi. Se un altro requisito di prontezza operativa è ritenuto necessario per un livello di servizio specifico, aggiungilo. Il livello 2 e il livello 1 potrebbero divergere in base alle esigenze del team.

Controlli di prontezza operativa suggeriti di livello 0

• Backup

• Gestione della capacità

• Consapevolezza dei clienti

• Disaster Recovery

• Registrazione

• Controlli logici degli accessi

• Release

• Checklist di sicurezza

• Metriche del servizio

• Resilienza del servizio

• Supporto

I servizi di livello 0 aggiungono la gestione della capacità, la consapevolezza dei clienti e i controlli logici degli accessi.

Come utilizziamo la prontezza operativa?

Una volta definiti i livelli di servizio, gli accordi sui livelli di servizio e i requisiti di prontezza operativa, ogni nuovo servizio viene assegnato a un livello di servizio e i team soddisfano i requisiti di disponibilità operativa come parte dello sviluppo del servizio. Questo processo garantisce che tutti i servizi di un determinato livello di servizio siano conformi agli stessi standard prima di essere distribuiti.

I requisiti di prontezza operativa non sono statici e possono essere aggiornati regolarmente man mano che i requisiti del team cambiano. Gli elementi di lavoro possono rendere i servizi esistenti conformi ai nuovi requisiti. È anche possibile non aggiornare i servizi esistenti per ottemperare ai requisiti aggiornati a seconda delle esigenze aziendali.

Indicatore dell'idoneità alla produzione

Integrare l'automazione è utile per verificare i requisiti di idoneità alla produzione. Per ogni servizio, la verifica automatizzata semplifica la creazione di una checklist che elenchi i requisiti di idoneità alla produzione applicabili a un servizio. I requisiti di idoneità alla produzione possono essere spuntati automaticamente quando vengono soddisfatti. Quando uno dei requisiti di idoneità alla produzione non è soddisfatto, l'indicatore di idoneità alla produzione dovrebbe essere rosso. Quando tutti i requisiti sono soddisfatti, l'indicatore di idoneità alla produzione dovrebbe essere verde.

Posiziona l'indicatore di idoneità della produzione nella pagina di destinazione principale del servizio specifico e in qualsiasi altra posizione utile. Un esempio di posizione utile per far emergere un indicatore di idoneità alla produzione potrebbe essere una scorecard Compass. L'aggiunta di un indicatore di idoneità alla produzione a una scorecard Compass di un servizio rende queste informazioni facili da trovare e fornisce un framework per applicare le best practice e identificare le aree che devono essere migliorate.

In conclusione...

I team hanno bisogno di tempo per sviluppare il processo di prontezza operativa. Iniziano definendo i livelli di servizio e gli accordi sui livelli di servizio, quindi definiscono quindi una serie di requisiti di prontezza operativa e determinano quali requisiti sono applicabili a ciascun livello di servizio. Una volta implementato il framework di base, ogni nuovo servizio può soddisfare i requisiti di prontezza operativa come parte del processo di sviluppo standard e i team avranno la certezza che il loro servizio sarà pronto per la produzione una volta che l'indicatore di idoneità alla produzione sarà verde.

Link supplementari

Per ulteriori informazioni sugli argomenti trattati in questo articolo, segui questi link.

• Best practice per l'efficienza operativa

• Obiettivi di livello di servizio

• Cos'è Checkops?

• Che cosa sono le metriche?